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Abstract 

We show that database schema validation and update processing problems such as view up- 
dating, materialized view maintenance, integrity constraint checking, integrity constraint 
maintenance or condition monitoring can be classified as problems of either abductive or 
deductive nature, according to the reasoning paradigm that inherently suites them. This 
is done by performing abductive and deductive reasoning on the event rules (Olive 1991), 
a set of rules that define the difference between consecutive database states In this way, 
we show that it is possible to provide methods able to deal with all these problems as a 
whole. 

We also show how some existing general deductive and abductive procedures may be 
used to reason on the event rules. In this way, we show that these procedures can deal 
with all database schema validation and update processing problems considered in this 
paper. 



1 Introduction 

It is largely agreed that databases should contain, at least, base facts, deductive 
rules (views), integrity constraints and, sometimes, conditions to monitor since 
these features, together with appropriate reasoning capabilities, facilitate program 
development and reuse (Grant and Minker 1992). Base facts represent extensional 
information; while deductive rules, integrity constraints and conditions to monitor 
represent intentional information, i.e. information that can be inferred from the 
extensional one. In particular, deductive rules define common knowledge shared by 
different users; integrity constraints define conditions that each state of the database 
is required to satisfy and conditions to monitor define information whose changes 
must be notified to the user. 

Database schema validation has become an important problem in database en- 
gineering, particularly since databases are able to define intentional information. 
Schema validation refers to the process of verifying whether a database schema 
correctly and adequately describes the user's intended needs and requirements 
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(Adrion, Branstad and Cherniavsky 1982). In general, preventing possible flaws 
during schema design will prevent those flaws from materializing as execution time 
errors or inconveniences. Among the typical problems related to database schema 
validation, we have satisfiability checking, redundancy of integrity constraints, view 
liveliness, etc. (Bry and Manthey 1986, Levy and Sagiv 1995, Decker, Teniente and 
Urpi 1996). 

Databases must also include an update processing system that provides users 
with a uniform interface through which they can request different kinds of updates, 
e.g. updates of base facts or updates of derived facts. In the presence of intentional 
information, updating a database is not a simple task since many issues have to be 
taken into account (Abiteboul 1988). Therefore, an important amount of research 
has been devoted to different database updating problems like view updating (Kakas 
and Mancarella 1990, Guessoum and Lloyd 1990, Teniente and Olive 1995, Con- 
sole, Sapino and Dupre 1995, Decker 1996, Lobo and Trajcevski 1997), materialized 
view maintenance (Gupta and Mumick 1995, Roussopoulos 1998), integrity con- 
straint checking (Sadri and Kowalski 1988, Kiichenhoff 1991, Olive 1991, Garcia, 
Celma, Mota and Decker 1994, Lee and Ling 1996, Staudt and Jarke 1996), in- 
tegrity constraint maintenance (Mocrkotte and Lockcmann 1991, Ceri, Fratcrnali, 
Paraboschi and Tanca 1994, Wiithrich 1993, Schewe and Thalheim 1994, Teniente 
and Olive 1995) or condition monitoring (Rosenthal, Chakravarthy, Blaustein and 
Blakeley 1989, Hanson, Chaabouni, Kim and Wang 1990, Qian and Widerhold 1991, 
Baralis, Ceri and Paraboschi 1998). 

Up to now, the general approach of the research related to database schema 
validation and update processing has been to provide specific methods for solving 
particular problems. Therefore, if we were interested in integrating these problems 
into current database technology, we should incorporate several methods into com- 
mercial database management systems. In our opinion, this is one of the main 
reasons of the difficulty of translating the huge amount of research in this area into 
practical applications. 

Solving these problems requires reasoning about the effect of an update on the 
database. Therefore, all these methods are either explicitly or implicitly based on a 
set of rules that define the changes that occur in a transition from an old state of a 
database to a new one, which is obtained as a result of the application of a certain 
transaction consisting of a set of base fact updates. 

Several authors have argued about the advantages of making explicit the rules 
that define changes on the database contents induced by the application of a trans- 
action when dealing with database updating problems (Bry 1990, Teniente and 
Urpf 1995, Denecker and Schreye 1998). These rules allow to guarantee that the 
updated database is as close as possible to the old database (which is the traditional 
assumption considered in database updating) and provide a high level of expres- 
siveness since they allow to reason jointly about both states involved in the update 
(which is specially useful when dealing with database updating problems). 

On the other hand, the role of deduction and abduction as reasoning paradigms is 
widely accepted. For instance, deduction has been used for query processing, while 
abduction has been applied to fault diagnosis, planning or default reasoning. In the 
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context of databases, abductive procedures have been proposed for view updating 
(Bry 1990, Console et al. 1995, Decker 1996) or satisfiability checking (Dcncckcr 
and Schreye 1998). However, we do not know precisely how many forms of reasoning 
are necessary for solving known database problems nor, in general, which database 
problems can be considered of deductive or of abductive nature, according to the 
reasoning paradigm that is more naturally suited to solve them. 

In this paper we show that database schema validation and update processing 
problems can be classified as either of deductive or of abductive nature. This is done 
by considering the event rules (Olive 1991), a particular case of rules that define the 
exact difference among consecutive database states, and by showing that reasoning 
deductively or abductively on these rules allows us to naturally specify and handle 
database problems. As we will see, problems like materialized view maintenance, 
integrity constraint checking or condition monitoring will be considered as naturally 
deductive, while problems like view updating, integrity constraint maintenance or 
enforcing condition activation as naturally abductive. 

This first result is an evolution of our work in (Tcniente and Urpf 1995) where 
we proposed two ad-hoc procedures to reason about the event rules that allowed us 
to classify database updating problems. We extend this work by showing that, in 
fact, we do not need ad-hoc procedures but that we can consider general reasoning 
paradigms like deduction and abduction. It follows from this result that general 
deductive and abductive procedures can be used to reason about the event rules and, 
hence, to deal with database schema validation and update processing problems. 

We also show how some existing general deductive and abductive procedures may 
be used to reason on the event rules. In this way, we show that these procedures 
can be used to deal with all database schema validation and update processing 
problems considered in this paper. This is illustrated by means of examples and we 
also point out some additional benefits gained by these procedures when reasoning 
on the event rules. Note that our goal is not that of comparing existing procedures 
but to show how to use them to reason on the event rules. 

Finally, we sketch how the event rules could be used to solve general abductive 
problems in addition to database schema validation and update processing prob- 
lems. 

Problems related to views, integrity constraints and conditions to be monitored 
will be encountered whenever we have a database able to deal with intentional infor- 
mation. We have developed our ideas for the particular case of deductive databases 
due to their clear and precise notation. However, our framework (and, thus, our 
conclusions) can be easily generalized to all kinds of databases containing views, 
integrity constraints and conditions like, for instance, relational, active, object or 
object-relational databases. 

This paper is organized as follows. The next section reviews basic concepts of 
deductive databases. Section 3 shortly presents the concepts of event, transition 
rules and event rules. Section 4 defines deductive and abductive reasoning on the 
event rules. Section 5 describes the most important problems related to schema 
validation and update processing and classifies them as either of deductive or of 
abductive nature. Section 6 shows how to use general deductive and abductive 
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procedures to reason on the event rules. Section 7 sketches the use of the event rules 
to solve general abductive problems. Finally, in section 8 we present our conclusions 
and point out future work. 

2 Basic Definitions and Notation 

We briefly review the basic concepts of deductive databases (Lloyd 1987, Ullman 
1989). We consider a first order language with a universe of constants, a set of 
variables, a set of predicate names and no function symbols. We will use names 
beginning with a capital letter for predicate symbols and constants and names 
beginning with a lower case letter for variables. 

A term is a variable symbol or a constant symbol. We assume that possible values 
for terms range over finite domains. If P is an m-ary predicate symbol and t\, . . . , t m 
are terms, then P(t\, . . . , t m ) is an atom. The atom is ground if every ti (i = 1, ... 
, m) is a constant. A literal is defined as either an atom or a negated atom. 

A fact is a formula of the form: P(ti, . . ., t m ) <— , where P(ti, . . ., t m ) is a ground 
atom. We will omit the arrow when denoting an atom. 

A deductive rule is a formula of the form: P(t\, . . . , t m ) <— L\ A . . . A L n , with m 
> 0, n > 1, where P{t\, . . . , t m ) is an atom denoting the conclusion and Li, . . . ,L n 
are literals representing conditions. P(ti, . . . , t m ) is called the head and Li A. . . AL n 
the body of the deductive rule. Variables in the conclusion or in the conditions are 
assumed to be universally quantified over the whole formula. The definition of a 
predicate P is the set of all rules in the database which have P in their head. We 
assume that the terms in the head are distinct variables. 

An integrity constraint is a formula that every state of the database is required 
to satisfy. We deal with constraints in denial form: <— L\ A . . . A L n , with n > 1, 
where the Li are literals and all variables are assumed to be universally quantified 
over the whole formula. We associate to each integrity constraint an inconsistency 
predicate Icn, where n is a positive integer, and thus they have the same form as 
deductive rules. Then, we would rewrite the former denial as lef <— L\ A. . .AL n . We 
call them integrity rules. More general constraints can be transformed into denial 
form by applying the procedure described in (Lloyd and Topor. 1984). 

We also assume that the database contains a distinguished derived predicate 1c 
defined by the n clauses: 1c <— Icn. That is, one rule for each integrity constraint Ici, 
i=l...n, of the database. Note that Ic will only hold in those states of the database 
that violate some integrity constraint and that it will not hold for those states that 
satisfy all constraints. 

A condition to be monitored is a formula of the form: Cond(t\, ...,t m ) <— L\ A 
. . . A L n , with m > 0, n > 1, where Cond{t\, t m ) is an atom and Li, . . . , L n are 
literals. Moreover, variables in Cond and in Li, . . . , L n are assumed to be universally 
quantified over the whole formula. Each condition to be monitored corresponds to 
a derived predicate for which certain changes have to be notified to the database 
user. 

A deductive database D is a tuple D = (EDB, IDB) where EDB is a set of facts, 
and IDB = DR U IC U Cond is a set of rules such that DR is a set of deductive 
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rules, IC a set of integrity rules and Cond a set of conditions to be monitored. The 
set EDB of facts is called the extensional part of the deductive database and the 
set IDB of rules is called the intentional part. We say that a deductive database 
is consistent if predicate Ic does not hold on it, i.e. if no integrity constraint is 
violated. 

We assume that deductive database predicates are partitioned into base and 
derived (view) predicates. A base predicate appears only in the extensional part 
and (possibly) in the body of deductive rules. A derived predicate appears only 
in the intentional part. Base and derived facts correspond to facts about base and 
derived predicates, respectively. 

As usual, we require that the deductive database before and after any updates 
is allowed, that is, any variable that occurs in a deductive rule, integrity rule or 
condition to be monitored has an occurrence in a positive literal of the body of the 
rule. In this paper, we deal with hierarchical 1 databases. Note that, in particular, 
this kind of databases does not allow to express recursive rules. 

3 The Event Rules 

Intuitively, a database is a dynamic system that changes over time. Changes are 
effected by EDB updates. These updates define a transition from an old state of 
the database to a new updated one. In this sense, schema validation and update 
processing problems can be viewed as database state transition problems. It is 
possible to define a set of rules that explicitly defines the possible transitions in 
terms of the difference between consecutive database states. Reasoning about these 
rules will allow to reason jointly about both states involved in the transition and, 
thus, to reason about the effect of the updates. 

The event rules explicitly define the difference between two consecutive database 
states. In the following, we shortly review the concepts and terminology of event 
rules, as presented in (Olive 1991), and we discuss on the possible use of other sets 
of rules instead of the event rules. 

3.1 Events 

Let D° be a deductive database, T a transaction and D™ the updated deductive 
database. We say that T induces a transition from D° (the old state) to D™ (the 
new state) . We assume for the moment that T consists of an unspecified set of base 
facts to be inserted and/or deleted. 

Due to the deductive rules, T may induce other updates on some derived predi- 
cates. Let P be one of such predicates, and let P° and P" denote the same predicate 
evaluated in D° and D™, respectively. Assuming that a fact P°(C) holds in D°, 
where C is a vector of constants, two cases are possible: 

1 Equivalent to nr-datalog--' rules, and with the same expressive power as the relational calculus 
(Abiteboul, Hull and Vianu 1995). 
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a.l. P"(C) also holds in D n . 

a. 2. P"(C) docs not hold in D n . 

and assuming that P"(C) holds in D™, two cases are also possible: 

b. l. P°(C) also holds in D°. 
b.2. P°(C) docs not hold in D°. 

In case a.2 we say that a deletion event occurs in the transition, and we denote it 
by <5P(C). In case b.2 we say that an insertion event occurs in the transition, and 
we denote it by iP(C). 

Formally, we associate to each predicate P an insertion event predicate lP and a 
deletion event predicate 5P, defined as: 

(1) Vx (tP(x) <-► P"(x) A -P°(x)) 

(2) Vx (5P(x) <-► P°(x) A -P"(x)) 

where x is a vector of variables. From the above, we then have the equivalencies: 

(3) Vx (P"(x) <-► (P°(x) A -i5P(x)) V tP(x)) 

(4) Vx (-.P n (x) «-» (->P°(x) A -uP(x)) V 5P(x)) 

We say that an event iP or 5P is a base event if P is a base predicate. Otherwise, it 
is a derived event. If P is a base predicate, then tP and SP facts represent insertions 
and deletions of base facts, respectively. Therefore, we assume from now on that 
a transaction T consists of an unspecified set of insertion and/or deletion base 
event facts. If P is a derived predicate, an integrity constraint or a condition to be 
monitored, tP and SP facts represent induced insertions and induced deletions on 
P, respectively. 

3.2 Transition Rules 

Let us consider a derived predicate P of the database. The definition of P consists of 
the rules in the deductive database having P in the conclusion. Assume that there 
are m (m > 1) such rules. For notation's sake, we rename predicate symbols in the 
conclusions of the m rules by Pi, P m , replace the implication by an equivalence 
and add the set of rules: 

(5) P <- P t i = 1 ... to 

i.e. one rule defining P for each derived predicate Pj, i = 1 ... to. 

Consider now one of the rules Pj(x) <-► L\ A . . . A L n . When this rule is to be 
evaluated in the new state, its form is P"(x) <-> L™ A ... A L™, where L™ (j = 1 
. . . n) is obtained by replacing the predicate Q of Lj by Q". Then, if we replace 
each literal in the body by its equivalent expression given in (3) or (4) we get a new 
rule which defines the new state predicate P™ in terms of old state predicates and 
events. 

More precisely, if L" is a positive literal Q"(xj) we apply (3) and replace it by: 
(Q?(x J -)A-.5Q J -(x J -)) VtQj-fo-) 
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and if L™ is a negative literal -iQ™(xj) we apply (4) and replace it by: 

(-Q°(x,)A^Q,(x,)) VJQjfe) 

After distributing A over V, we get the set of transition rules for P™. Notice that 
there are 2 kl such rules (where kj is the number of literals in the P™ rule) and that 
literals in each rule can be of three types: old database literals, base event literals 
and derived event literals. 

Example 1 

Consider the rule Conti(x) <-> Sign(x) A-iFail-ex(x) stating that contracted people 
are those who signed an agreement and did not failed the exam. In the new state, 
this rule has the form Cont"(x) <-> Sign™(x) A^Fail-ex™(x). Then, replacing Sign™(x) 
and -i Fail-ex" (x) by their equivalent expressions given by (3) and (4) we get: 

Cont 7 l(x) <-> [(Sign°(x) A -^5Sign{x)) V bSign(x)] A 

[(^Fail-ex°(x) A ->LFail-ex(x)) V 5Fail-ex{x)\ 

and, after distributing A over V, we get the following transition rules: 

Cont™ (x) <— Sign°(x) A -^SSign(x) A ~^F ail-ex° (x) A ~^bFail-ex{x) 
Cont™ (x) <— Sign°{x) A -^SSign(x) A dFail-ex(x) 
Cont™(x) <— iSign(x) A -^Fail-ex" (x) A -^iFail-ex{x) 
Cont"(x) <— tSign(x) A 5Fail-ex(x) 

Intuitively, it is not difficult to see that the first rule states that Cont(X) will be 
true in the new state of the database if Sign(X) was true in the old state, Fail-ex(X) 
was false in the old state and no change of Sign(X) and Fail-ex(X) is given by the 
transition. In a similar way, the second rule states that Cont(X) will be true in the 
new state if Sign(X) was true and it has not been deleted and if Fail-ex(X) has 
been deleted during the transition. A similar, intuitive, interpretation can be given 
for the third and forth rules. 

For simplicity of presentation, we will omit the subscript when a predicate P is 
defined by only one rule and we will omit the superscript for denoting old database 
predicates. 

3.3 Insertion and Deletion Event Rules 

Let P be a derived predicate. Insertion and deletion event rules of predicate P are 
defined respectively as: 

(6) tP(x) <- P"(x) A-P°(x) 

(7) <5P(x) <- P°(x) A^P n (x) 

where P refers to the current (old) database state and P" refers to the transition 
rule of P. These event rules define the induced changes that happen in a transition 
from an old state of a database to a new, updated state. Note that they depend 
only on the rules of the database, being independent of the stored facts and of any 
particular transaction. 
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We would like to point out that these rules can be intensively simplified, as 
described in (Olive 1991, Urpf and Olive 1992, Urpi and Olive 1994). By simplifying 
the event rules we obtain a set of scmantically equivalent rules, but with a lower 
evaluation cost. The automatic generation and simplification of the event rules has 
been implemented in a SunOS environment by means of Quintus Prolog. In this 
paper, we will consider the simplified version of the event rules. 

Definition 1 

Let D = (EDB, IDB) be a deductive database. The augmented database associated 
to D is the tuple A(D) = (EDB, IDB*), where IDB* contains the rules in DR U IC 
U Cond and their associated simplified transition and event rules. 

Example 2 

Given the following database D = (EDB,IDB): 

Sign(John) 
Fail-ex(John) 

Cont(x) <— Sign(x) A-Eail-ex(x) 

the corresponding augmented database A(D) is the following: 

Sign(John) 
Fail-ex(John) 

Cont(x) <— Sign(x) A ^Fail-ex(x) 

tCont(x) <— Sign(x) A -i<5Sign(x) A (5Fail-ex(x) 

tCont(x) <— iSign(x) A -i Fail-cx(x) A ^tFail-ex(x) 

tCont(x) <— iSign(x) A <5Fail-ex(x) 

JCont(x) <— Cont(x) A tFail-ex(x) 

<5Cont(x) <— (5Cont(x) A -i Fail-ex(x) 

3-4 Using other Rules Instead of the Event Rules 

We will use the event rules to provide the basis of our framework for specifying and 
handling schema validation and update processing problems. However, since our 
framework is only based on the definition of event given in (1) and (2) (see Section 
3.1), we could use any set of rules that defines the difference between consecutive 
states of the database, instead of the event rules, provided that they preserve the 
event definition. In this section we show two different sets of rules that could had 
been used also. 

Assume that we have the following deductive rules: 

P(x) <— Q(x) A R(x) 
R(x) <- S(x) 

If we simply consider the definition of transition and event rules without applying 
any simplification, we would have: 

«P(x) <-P n (x) A^P(x) 
iR(x) <- R n (x) A -.R(x) 
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<5R(x) <- R(x) A -iR" (x) 

P"(x) <— Q(x) A -.SQ(x) A R(x) A -.5R(x) 

P"(x) <— Q(x) A -.5Q(x) A iR(x) 

P"(x) <- iQ(x) A R(x) A -.5R(x) 

P n (x) <- tQ(x) A iR(x) 

R n (x) <— S(x) A -.5S(x) 

R n (x) «- tS(x) 

On the other hand, by adapting the rules generated by Kiichenhoff (Kuchcnhoff 

1991) to our terminology, we would obtain: 

tP(x) <— Q(x) A -.5Q(x) A iR(x) A -.P(x) 
tP(x) <- iQ(x) A R(x) A -n£R(x) A -P(x) 
tP(x) <- tQ(x) A tR(x) A -P(x) 
tR(x) tS(x) 
5R(x) 5S(x) 

Note that Kiichenhoff's rules provide some simplifications with regards to the 
non-simplified event rules. For instance, insertion event rules about R do not check 
that R was false in the old state of the database. A similar simplification is given 
for deletion event rules about R. However, no simplification is applied for the rules 
defining events on P. 

Finally, the simplified insertion event rules for P according to (Urpi and Olive 

1992) are the following: 

tP(x) <— Q(x) A -.SQ(x) A lR(x) 
tP(x) <- tQ(x) A R(x) A -.(JR(x) 
tP(x) <- tQ(x) A iR(x) 
tR(x) tS(x) 
5R(x) <- SS(x) 

Note that, in addition to the simplifications already provided by Kuchcnhoff, 
these rules include also simplifications involving the event rules for P. 

It is not difficult to see that the three sets of rules are semantically equivalent and 
define the same transitions between consecutive database states. The event defini- 
tion is preserved in all cases. The only difference relies on the kind of optimizations 
that have been considered. In fact, we could also think about other sets of rules that 
incorporate additional optimizations (see for instance (Urpi and Olive 1994) which 
incorporates the knowledge provided by the integrity constraints into such set of 
rules). The differences among possible sets of rules imply advantages or inconve- 
niences as far as efficiency is concerned, but not regarding the ability of solving the 
problems we deal with in this paper. Thus, our framework does not depend on any 
particular set of rules. 



4 Reasoning on the Event Rules 

There is a big amount of problems related to database schema validation and to 
update processing. Unfortunately, the general approach considered by previous re- 
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search in this area has been to deal with each problem in an isolated way. So, it 
is unusual to find a method able to handle several of the previous problems. This 
limitation can be overcome by considering a set of rules that explicitly define the 
difference between two consecutive database states and by performing deductive 
and abductive reasoning on these rules. 

The role of deduction and abduction as reasoning paradigms is widely accepted. 
Deduction is an analytic process based on the application of general rules to par- 
ticular cases, with the inference of a result. Abduction is another form of synthetic 
reasoning which infers the case from the rule and the result. 

The event rules define the exact changes, either on base as on derived predicates, 
produced as a consequence of the application of a given transaction to a database 
state. Deductive and abductive reasoning can be performed on those rules. As 
we will see, performing deductive reasoning on the event rules defines changes on 
derived predicates induced by changes on base predicates. On the other hand, per- 
forming abductive reasoning on the event rules defines changes on base predicates 
needed to satisfy changes on derived predicates. In this way, reasoning deductively 
or abductivcly on the event rules provides the basis for solving database schema 
validation and update processing problems in a uniform way. 

In fact, as stated in Section EP1 any set of rules that precisely defines the differ- 
ence between consecutive database states could also be used. Due to our previous 
experience with the event rules, we have considered them in this paper. 

4-1 Reasoning Deductively on the Event Rules 

Deduction is concerned with inferring consequences from facts via deductive rules. 
For instance, given a deductive rule P(x) <— Q(x) and a fact Q(A), deduction infers 
P(A) as a consequence of Q(A). Thus, deductive reasoning is suitable among other 
things for finding correct answers to queries. 

Definition 2 

Let D = (EDB, IDB) be a deductive database and G a goal Li A . . . A L n . A correct 
answer to G over EDB is a substitution 9 for variables of G such that GO is a logical 
consequence of EDB U IDB, i.e. EDB U IDB |= G0. 

Since event rules define the changes that occur in a transition from an old state of 
a database to a new one as a consequence of the application of a given transaction, 
by considering deduction in the context of the augmented database we can also 
define how to reason deductively on the event rules. 

Definition 3 

Let D = (EDB, IDB) be a deductive database, A(D) = (EDB, IDB*) its corre- 
sponding augmented database, T a transaction consisting of a set of ground base 
event facts, u a derived event. The deduced consequences on u due to the applica- 
tion of T is the set 9 of correct answers to EDB U IDB* UTUu. Note that each 
correct answer 9i £ 9 defines a ground derived event u9i induced as a consequence 
of the application of T. 
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Thus, reasoning deductively on the event rules defines changes on derived predi- 
cates induced by changes on base predicates, since 9 defines all ground facts about 
u induced by the application of T to the current state of the database. 

As an example, given the database of Example [21 and the transaction T={<5Fail- 
cx(John)}, it is not difficult to see that reasoning deductively on the event rules 
allows to deduce that T induces tCont(John), i.e. 6 ={x=John}. 

4-2 Reasoning Abductively on the Event Rules 

Abduction is aimed at looking for hypothesis that explain a given observation, 
according to known laws usually specified by means of deductive rules. Abduction 
(in the absence of integrity constraints) is traditionally defined as follows: Given 
a set of sentences T (a theory presentation) and a sentence G (observation), the 
abductive task consists of finding a set of sentences A (abductive explanation for 
G) such that: 

(1) T U A h G 

It is usually considered that A consists of atoms drawn from predicates explicitly 
indicated as abducible (those whose instances can be assumed when required). 
Therefore, an abductive framework is a pair -< T, Ab >-, where Ab is the set of 
abducible predicates, i.e. A C Ab 2 . 

By considering these ideas in the context of the augmented database, we can 
also define how to reason abductively on the event rules. In this case, abducible 
predicates correspond to base event facts since this is the only possible way to 
physically update a database. 

Definition 4 

Let us consider a deductive database D = (EDB, IDB) and its corresponding aug- 
mented database A(D) = (EDB, IDB*). We can define an associated abductive 
framework -< EDB U IDB*, Ab >~, where Ab corresponds to the set of base event 
predicates. Now, given a ground derived event u, we can define an abductive expla- 
nation for u in -< EDB U IDB*, Ab y to be any set Tj consisting of ground facts 
about predicates in Ab such that: 

- EDB U IDB* U T, |= m 

An explanation Tj is minimal if no proper subset of Tj is also an explanation, 
i.e. if it does not exist any explanation Tj for u such that Tj C Tj. 

The previous condition states that the update request is a logical consequence of 
the database updated according to Tj. Thus, abductive reasoning on the event rules 
defines changes on base predicates needed to satisfy a given change on a derived 
predicate. 

As an example, given the database of Example[2]and the derived event tCont(John), 
it is not difficult to see that T={i5Fail-ex(John)} is a minimal abductive explanation 

2 Here and in the rest of the paper we will use Ab to indicate both the set of abducible predicates 
and the set of all their variable-free instances. 
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for tCont(John). That is, the insertion of Cont(John) is satisfied by the deletion of 
Fail-ex(John). 

In general, the result of applying abductive reasoning may not be unique. That 
is, several sets Tj of base event facts that satisfy a derived event may exist. Each 
possible set Tj constitutes a possible transaction that applied to the database will 
accomplish the desired change on the derived predicate. Minimal explanations are 
usually of particular interest, specially when we deal with database updating prob- 
lems since they allow to minimize the difference between the old and the new states 
of the database. 

If no solution Tj is obtained then either the requested update cannot be satisfied 
only by changes on the EDB or the current database state already satisfies the 
intended effect of the request (e.g. an insertion of P is requested into a database 
that already satisfies P). Note that in the latter case we do not obtain a solution 
with the empty set since, when taking the event definition into account, an insertion 
of P can only be explained if the old state of the database does not satisfy P (resp. 
a deletion of P can only be explained if P is satisfied) . 

With this framework, the basic strategy of a proof procedure for computing 
Tj is the following. Given, for instance, an update request for inserting P, the 
update procedure tries to solve abductively the goal <— iP in -< EDB U IDB*, Ab y 
generating a set Tj of abducibles such that Tj satisfies the above condition. Before 
abducing a base event, we have to check that its definition is satisfied. That is, for 
abducing an event SP we require P to be true in the old state of the database while 
for tP we require P to be false. The set Tj generated by abduction for an update 
request u constitutes a transaction that, applied to the current state of the EDB, 
will satisfy u. 

Given an event (base or derived) Uj to be explained, abductive reasoning on the 
event rules can also be used to determine sets of base events that ensure that a 
certain derived event Uj is not induced by the explanations of Uj. In this case, the 
abductive interpretation defines changes on base predicates needed to satisfy that 
a certain change on a derived predicate does not occur as a consequence of the 
application of the explanations of Uj. 

Definition 5 

Let D be a deductive database D = (EDB, IDB), its corresponding augmented 
database A(D) = (EDB, IDB*) and its associated abductive framework -< EDB U 
IDB*, Ab y. Now, given a positive event Wj and a negative derived event ->Uj such 
that Ui A -iiij is allowed, we can define the abductive explanation for Uj A -<Uj in 
-< EDB U IDB*, Ab y to be any set Tj consisting of ground facts about predicates 
in Ab such that: 

- EDB U IDB* UT.h Wj 

- EDB U IDB* U T t ty= Uj 

The first condition states that Uj is a logical consequence of the database up- 
dated according to Tj, while the second states that Uj it is not. Note that if the 
explanations of Uj alone do not induce Uj, then they are already valid abductive 
explanations. 
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As an example, given the database of Example[2]and the positive event tSign(Mary) 
and the negative event ^tCont(Mary), we have that T={tSign(Mary), iFail-ex(Mary)} 
is a minimal abductive explanation for tSign(Mary) A -iiCont(Mary). Note that 
iSign(Mary) alone would induce tCont(Mary). However, adding iFail-ex(Mary) to 
T does not induce tCont(Mary) any more since Cont(Mary) will be false in the new 
database state. 

Two special cases are of particular interest. First, when the negative derived event 
is -iilc it is guaranteed that the obtained explanations do not induce any insertion 
of an integrity constraint. Thus, the new database state will be consistent if the old 
database state was already consistent. Second, if the positive event is base (i.e. a 
transaction T), abductive reasoning on the event rules determines possible sets Sj 
of ground base event facts that, appended to T, ensure that the application of any 
of the resulting transactions Tj = Sj U T does not induce Uj . Note that if T alone 
does not induce Uj, then T itself is a valid transaction. 

This framework can be easily generalized to reason abductively on sets of positive 
and negative events. 

5 Deductive or Abductive Nature of Database Problems 

Deduction and abduction provide a uniform way to reason about the event rules 
and, in general, about any set of rules that explicitly define the exact difference 
between two consecutive database states. Moreover, either views (i.e. derived pred- 
icates) or integrity constraints or conditions to be monitored are uniformly defined 
by means of deductive rules and they are only distinguished by the different se- 
mantics endowed to the head of the rule. Thus, a view defines common knowledge 
shared by different users, an integrity constraint defines a situation that must never 
happen and a condition to be monitored defines an information whose changes must 
be reported to the user. 

Therefore, given a derived predicate P(x) defined by the rule P(x) <— Q(x) 
A -iR(x) , P can be expressed as: 

View(x) <— Q(x) A -.R(x) 
Icl(x) <- Q(x) A^R(x) 
Cond(x) <— Q(x) A -.R(x) 

according to the concrete semantics that we would like to endow to P. 

Now, reasoning deductively or abductively on the event rules corresponding to 
View, Icl and Cond we may classify as naturally deductive or naturally abductive 
the database schema validation and update processing problems. 

This is summarized in Tabled Each row corresponds to the form of reasoning to 
be applied to the event rules of P and to the relevant events about P (i.e. iP, 5P, T 
A-><P or T A-«5P; being T a transaction) to reason about. Each column considers a 
different semantics to be endowed to P. Finally, each resulting cell defines a possible 
database schema validation or update processing problem that can be specified in 
terms of that form of reasoning and of the considered semantics. 

In the rest of this section, we briefly review database schema validation and 
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Maintaining DB 
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Table 1 . Classification of Database Problems 

update processing problems and we show how they can be handled by means of 
deductive or abductive reasoning, according to the classification provided in Table 
□ 

5.1 Schema Validation and Update Processing Problems 

The correct use of a database involves three different tasks: Schema Validation, to 
guarantee that the database schema satisfies the user's intended needs and require- 
ments; Query Processing, to be able to give efficient and correct answers to the 
user' queries; and Update Processing, to be able to correctly perform updates to the 
database contents. In general, several problems may arise when dealing with each 
of these tasks (Teniente 2000). We will consider here only the problems encountered 
during schema validation and update processing, since query processing is beyond 
the scope of this paper. 

Example 3 

Consider the following flawed database schema to be validated: 



(DR.l) Some-cand <— Cand(x) 

(DR.2) Emp(x) <- Cand(x) A Cont(x) 

(DR.3) Cont(x) <- Sign(x) A ^Fail-ex(x) 

(DR.4) App(x) <- Cand(x) 

(Id) Icl(x) <- App(x) A Sign(x) 

(IC.2) Ic2(x) <— App(x) A -iHas-account(x) 

(IC.3) Ic3(x) <— -iSome-cand 

(IC.4) Ic4(x) <- Cand(x) A -App(x) 

(IC.5) Ic5(x) <- App(x) 

(IC.6, IC.10) Ic <- Ici, for i=l.„5 

(Cond.l) Condl(x) <- Cand(x) A ^Cont(x) 
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(Cond.2) Cond2(x) <- Emp(x) A ^Cont(x) 

This schema defines four derived predicates (through deductive rules DR.l to 
DR. 4): Some-cand, Emp (employee), Cont (contracted person) and App (applicant). 
A person is an applicant if he is a candidate (Cand) . A person is contracted if he 
signed an agreement (Sign) and he did not fail the exam. Employees are candidates 
that have a contract. Finally, Some-cand is true if the database contains, at least, 
one candidate. 

The schema contains also five integrity constraints (defined by integrity rules 
IC.l to IC.5). Icl states that it is not possible to have applicants that have signed 
an agreement. Ic2 states that it is not possible to be applicant and not to have 
an account. Ic3 states that there must be some candidate. Ic4 states that it is not 
possible to be candidate and not be applicant. Finally, Ic5 states that the database 
may not contain any applicant. 

The schema contains also two conditions to be monitored. The first one is used to 
notify changes on the populations of applicants that do not have a contract and the 
second one changes on the populations of employees that do not have a contract. 

5.2 Schema Validation Problems 

In general, we cannot be completely sure that a certain database schema adequately 
describes the structure of the information that we want the database to contain. 
At first glance, we could perhaps detect that a certain deductive rule or integrity 
constraint is not precisely defined, as it might happen with IC.5 above, but it is 
very difficult to assess whether a certain schema does not present critical flaws. 
Detecting and removing flaws during schema design time will prevent these flaws 
from materializing as run-time errors or other inconveniences during operation time. 
(Decker et al. 1996) identified several desirable properties that a database schema 
should satisfy. 

5.2.1 Satisfiability Checking 

A database schema is satisfiable if there exists an EDB for which no integrity 
constraint is violated (Bry and Manthey 1986), also mentioned in (Bry, Decker and 
Manthey 1988, Inoue, Koshimura and Hasegawa 1992). Clearly, a non-satisfiablc 
schema is not useful since it does not accept any extensional information. 

As an example, the previous database schema is not satisfiable for any EDB. The 
empty EDB is not a proper EDB since it violates Ic3. Then, we need to consider 
an EDB with at least one candidate, let us say John. However, this is not enough 
since Ic4 would then be violated. So, John must also be an applicant but this is 
not possible since Ic5 impedes it. As a consequence of detecting that the previous 
schema is not satisfiable, we assume that the database designer decides to discard 
Ic3 and Ic5. 

Satisfiability checking can be naturally specified as performing abductive reason- 
ing on the event rules associated to <5Ic provided that Ic holds with an empty EDB. 
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If there exists at least one abductive explanation for 81c in -< EDB U IDB*, Ab y, 
with IDB = DR U IC, then the integrity constraints are satisfiable. Note that if 
Ic does not hold in the state corresponding to the empty EDB, all constraints are 
already satisfied in that state. 

Note that, since satisfiability checking is to be determined at schema validation 
time, we are considering the empty EDB for checking this property. For the same 
reason, we will also use the empty EDB for checking other problems related to 
database schema validation. 

5.2.2 Absolute Redundancy of an Integrity Constraint 

Intuitively, an integrity constraint is absolutely redundant if integrity does not 
depend on it. That is, if it can never be violated. Obviously, an absolute redundant 
integrity constraint is not useful since it does not add any additional information 
to the information already provided by the rest of the schema. 

For instance, integrity constraint Ic4 is absolutely redundant since the deductive 
rule DR. 4 prevents Ic.4 to be violated for any EDB. Therefore, the database designer 
has to modify the schema to remove this absolute redundancy. In this case, we 
assume that he decides to discard DR.4. 

Given an integrity constraint 7c;, absolute redundancy can be naturally specified 
as performing abductive reasoning on the event rules associated to ulci. If there 
exists at least one abductive explanation for lIci in -< EDB U IDB*, Ab y, with 
IDB = DR U IC, then lei is not absolutely redundant since it can be violated in 
some state of the database. In particular, in the database state that we obtain as a 
result of applying the obtained abductive explanation. 

5.2.3 View Liveliness 

A derived predicate P (i.e. a view) is lively if there exists an EDB in which at least 
one fact about P is true. That is, predicates which are not lively correspond to 
views that are empty in each possible state of the database. Such predicates are 
clearly not useful and probably ill-specfied. This definition of "liveliness" essentially 
coincides with the definition of "satisfiable" in (Levy and Sagiv 1995). 

For instance, predicate Emp as defined in Example [21 is not lively. The reason is 
that a fact Emp(X) requires Cand(X) and Sign(X) to be true at the same time. 
However, since nobody can be a candidate without being an applicant (Ic.4) and 
nobody can be an applicant and to have signed an agreement (Ic.l), no person X 
can be an employee. We assume that the database designer decides to correct this 
flaw by redefining Ic.l as Icl'(x) <— App(x) A Sign(x) A -i Has- account (x). 

In our framework, provided that no fact about View holds in the empty EDB, view 
liveliness can be specified as reasoning abductively on the event rules of tView(x). 
If there exists at least one abductive explanation for a certain event tView(X) in -< 
EDB U IDB*, Ab then View is lively since it is possible to reach a state where at 
least a fact View(X) is true. Otherwise, View is not lively. Note that if some fact 
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about View holds in the empty EDB, then View is already lively in that state and 
there is no reason to ask about this property. 

Let us review the Example with the flaws corrected up to now: 



(DR.l) Some-cand <— Cand(x) 

(DR.2) Emp(x) <- Cand(x) A Cont(x) 

(DR.3) Cont(x) <- Sign(x) A -,Fail-ex(x) 

(ICE) Icl(x) <- App(x) A Sign(x)A ^Has-account(x) 

(IC.2) Ic2(x) <— App(x) A -i Has- account (x) 

(IC.4) Ic4(x) <- Cand(x) A -App (x) 

(IC.6,IC7, IC.9) Ic <- Ici, for i=l,2, 4. 

(Cond.l) Condi (x) <- Cand(x) A ^Cont (x) 

(Cond.2) Cond2(x) <- Emp(x) A -.Cont (x) 



5.2-4 Relative Redundancy of Integrity Constraints 

Relative redundancy is similar to absolute redundancy but, in this case, an integrity 
constraint (or a set of constraints) is relatively redundant if it is always satisfied in 
all states that satisfy the rest of the constraints. Again, such a redundancy should 
be detected and redundant constraints should not be considered during update 
processing. 

In our example, we can see that Icl' is relatively redundant since it is entailed by 
Ic2. Therefore, we assume that the database designer decides to discard Icl' since 
the resulting database will admit the same consistent states. 

Given an integrity constraint Jc;, rlative redundancy can be naturally specified 
as performing abductive reasoning on the event rules associated to lIci. Ici is 
not relatively redundant if there exists at least one abductive explanation for <— 
tlci A -.dc in -< EDB U IDB*. Ab y, with IDB = DR U IC - { Ic <- Ic,}. 

5.2.5 Condition Validation 

Condition validation refers to the problem of determining whether it is possible to 
change the contents of a certain condition Cond(x). That is, to determine whether 
exists at least one transaction that, if applied to the database, could activate a 
certain condition iCond(X) or <5Cond(X). Clearly, a condition that can never be 
activated is probably ill-specified since the active behaviour of the database does 
not depend on it. This can be useful, for instance, to provide the database designer 
with a tool for validating certain aspects of the condition definition and, hence, 
of the active behaviour of the database. This problem is very important in the 
context of active databases since this technology is mainly based on the extensive 
use of conditions to be monitored, which are the core of Condition- Action (CA) 
and Event-Condition- Action (EC A) rules (Widom and Ceri 1996). 

For instance, condition Cond2 as defined in Example is not valid since no 
insertion and no deletion can be induced on it. The reason is that, by the deductive 
rule DR.2, employees must have a contract and, then, it is not possible to have 
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employees without a contract. So, we assume that the database designer decides to 
discard condition Cond2. 

In a similar way that view liveliness, changes induced in a given condition, 
Cond(x), can be specified as reasoning abductively on the event rules of tCond(x) 
and <5Cond(x). If there exists at least one abductive explanation for a certain event 
iCond(X) or JCond(X) in -< EDB U IDB*, Ab y, then the condition can be acti- 
vated. 

5.3 Update Processing Problems 

Once the database schema is validated, we are ready to perform updates to the 
database contents. Several problems will arise when processing the requested up- 
dates (Teniente and Urpi 1995). To illustrate these problems, we consider the 
schema we have previously validated and we will assume that the database contains 
several base facts. Note that, now, the schema is satisfiable, all predicates are lively 
and no integrity constraint is either absolutely nor relatively redundant. 

Example 4 

The following database will be considered to deal with update problems related to 
views and integrity constraints: 



(F.l) 


Sign(John) 


(F.2) 


Fail-ex(John) 


(DR.l) 


Some-cand <— Cand(x) 


(DR.2) 


Emp(x) <— Cand(x) A Cont(x) 


(DR.3) 


Cont(x) <— Sign(x) A -iFail-ex(x) 


(IC.2) 


Ic2(x) <— App(x) A -iHas-account(x) 


(IC.4) 


Ic4(x) <- Cand(x) A ^App (x) 


(IC.7, IC.9) 


Ic <— Ici, for i=2, 4. 


(Cond.l) 


Condi (x) <- Cand(x) A -.Cont (x) 



5.3.1 Integrity Constraint Checking 

There exists a large cumulative effort in the field of integrity constraint checking 
(Sadri and Kowalski 1988, Kuchenhoff 1991, Olive 1991, Garcia et al. 1994, Lee and 
Ling 1996, Staudt and Jarke 1996). Given a consistent database and a transaction 
(i.e. a set of insertions and deletions of base facts), integrity constraint checking 
is devoted to incrementally, i.e. efficiently, determine whether the application of 
this transaction to the current database violates some integrity constraint. In this 
case, the transaction is rejected since, otherwise, its application would lead to an 
inconsistent database state. 

Given a transaction T, integrity constraint checking can be naturally specified 
in our framework as performing deductive reasoning on the event rules associated 
to (-Ic, provided that Ic does not hold. The deduced consequences on tic are either 
the identity substitution or no correct answer of EDB U IDB* U T U -i Jc exists. 
In the first case, T induces an insertion of Ic and, therefore, it must be rejected 
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because it violates some integrity constraint. Otherwise, T does not violate any 
integrity constraint and it can be successfully applied. As it happens with materi- 
alized view maintenance, efficiency of the process is ensured since reasoning about 
the transaction and the event rules allows to compute only the updates induced by 
this transaction. 

As an example, assume that the database of Example 01 contains also the facts 
App(Peter) and Has-account (Peter). Reasoning deductively on the event rules of 
Ic2 we could determine that the transaction T={<5Has-account(Peter)} induces the 
insertion of Ic2 (Peter) and, thus, of Ic and would lead the database to an inconsis- 
tent state. 

5.3.2 Integrity Constraint Maintenance 

The main drawback of integrity constraint checking is that the user may not know 
which changes to the transaction are needed to guarantee that its application does 
not violate any integrity constraint. Integrity constraint maintenance is aimed at 
overcoming this drawback: given a consistent database state and a transaction T 
that violates some integrity constraint, the problem is to find repairs, that is, an 
additional set of insertions and/or deletions of base facts to be appended to T such 
that the resulting transaction T' satisfies all integrity constraints. In general, there 
may be several repairs and the user must select one of them. Eventually, if no such 
repair exists then the original transaction must be rejected. Several methods have 
been proposed to deal with this problem (Moerkotte and Lockemann 1991, Ceri et 
al. 1994, Wuthrich 1993, Schewe and Thalheim 1994, Teniente and Olive 1995). 

Given a consistent database state and a transaction T, integrity constraint main- 
tenance can be specified in our framework as performing abductive reasoning on 
the goal <— T A -idc. Thus, possible abductive explanations for T A — itlc in -< EDB 
U IDB*, Ab y, with IDB = DR U IC, correspond to the possible transactions T', 
T C T', that maintain database consistency. 

As an example, consider again the database of Example 0] and assume that the 
transaction T={/App(Claire)} wants to be applied to the database. Reasoning ab- 
ductively on tApp(Claire) A~>ilc we obtain the transaction T'={tApp(Claire), tHas- 
account (Claire)} which satisfies the original transaction and maintains the database 
consistent. 

5.3.3 View Updating 

View updating is concerned with determining how a request to update a view, i.e. 
to update the contents of a derived predicate, must be appropriately translated 
into updates of the underlying base facts. In general, several translations may exist 
and the user must select one of them. This problem has attracted much research 
during the last years in deductive databases (Kakas and Mancarella 1990, Guessoum 
and Lloyd 1990, Teniente and Olive 1995, Console et al. 1995, Decker 1996, Lobo 
and Trajcevski 1997) and it has been already identified as an abductive problem 
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(Console et al. 1995, Decker 1996, Denecker and Schreye 1998, Inoue and Sakama 
1999) 

View updating can be naturally specified as performing abductive reasoning on 
the event rules of tView(X) or <5View(X), where View(X) is the derived fact to be 
inserted or deleted, respectively. The abductive explanation for iView(X) defines 
possible sets of base fact updates (i.e. transactions) that satisfy the insertion of 
View(X), while the abductive explanation for <5View(X) defines possible sets of 
base fact updates that satisfy the deletion of View(X). 

For instance, in Example 01 reasoning abductively on the event rules of Cont 
we can determine that the view update request iCont(John) is satisfied by the 
transaction T={£Fail-ex(John)}. 

In principle, it may happen that some translations corresponding to a given view 
update request do not satisfy the integrity constraints. For this reason, view up- 
dating is usually combined with problems related to integrity constraints. Possible 
ways of performing this combination will be explained in Section [5.51 

5.3.4 Materialized View Maintenance 

A view can be materialized by explicitly storing its contents in the extensional 
database. This can be useful, for instance, to improve efficiency of query process- 
ing. Given a transaction, materialized view maintenance consists of incrementally, 
i.e. efficiently, determining which changes are needed to update accordingly the 
materialized views (see (Gupta and Mumick 1995, Roussopoulos 1998) for a state- 
of-the-art reports). 

Given a transaction T and a materialized view View(x), materialized view main- 
tenance can be naturally specified as performing deductive reasoning on the event 
rules associated to tView(x) and JView(x). That is, deduced consequences for 
iView(x) and for (SView(x) correspond, respectively, to the insertions and to the 
deletions to be performed on View(x). Efficiency of the process is ensured since rea- 
soning about the transaction and the event rules allows to incrementally compute 
only the updates induced by this transaction. 

For instance, if we assume that predicate Cont(x) in Example 2] is materialized, 
reasoning deductively on the event rules of Cont we can determine that the trans- 
action T={(5Fail-ex(John)} induces the insertion of Cont(John) in the materialized 
view. 

5.3.5 Preventing Side Effects 

Due to the deductive rules, undesired updates may be induced on some derived 
predicates when applying a transaction. We say that a side effect occurs when 
this happens. The problem of preventing side effects (Teniente and Olive 1995) is 
concerned with determining a set of base fact updates which, appended to a given 
transaction, ensure that the application of the resulting transaction to the current 
state of the database will not induce the undesired side effects. In general, several 
solutions may exist and the user must select one of them. 
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Ensuring that a transaction T will not induce an insertion or a deletion of a 
derived fact View(X) can naturally be specified as reasoning abductively on {T 
A -itView(X)} or on {T A -iJView(X)}, respectively. The former defines sets T' of 
base fact updates, which are supersets of T, needed to guarantee that the insertion 
of View(X) is not induced by T, while the latter defines sets T' of base fact updates, 
again supersets of T, needed to satisfy that the deletion of View(X) is not induced. 

For instance, reasoning abductively on tSign(Mary) A ^tCont(Mary) we can 
prevent that the transaction T={iSign(Mary)} will not induce the insertion of 
Cont(Mary). This is done by considering T'={tSign(Mary), tFail-ex(Mary)} in- 
stead of T, which is also given by this abductive interpretation. 

5.3.6 Condition Monitoring 

Condition monitoring refers to the problem of incrementally monitoring the changes 
on a condition induced by a transaction that consists of a set of base fact updates 
(Rosenthal ct al. 1989, Hanson et al. 1990, Qian and Widerhold 1991, Baralis et 
al. 1998). 

As an example, applying the transaction T={iCand(Peter)} to the database of 
Example 01 would induce /.Condi (Peter). That is, due to the application of T, Peter 
would be a candidate without a contract. 

In our framework, changes induced in a condition Cond(x), are specified as 
performing deductive reasoning on the events rules associated to tCond(x) and 
5Cond(x). The former, (.Cond(x), defines the changes meaning that x satisfy the 
condition after the application of the transaction, but not before. The latter, 5Cond(x), 
defines the changes meaning that x satisfy the condition before the application of 
the transaction, but not after. 

5.3.7 Enforcing Condition Activation 

Enforcing condition activation refers to the problem of obtaining the possible trans- 
actions that, if applied to the current state of the database, would induce an activa- 
tion of a given condition. For instance, the transaction Ti={iCand(Peter)} would 
induce the condition iCondl (Peter). 

In our framework, enforcing condition activation is specified reasoning abduc- 
tively on tCond(X) or <5Cond(X), where both correspond to the conditions to be 
enforced. The former defines possible transactions that will induce X to satisfy 
the condition after their application, but not before. The latter, defines possible 
transactions that will induce X not to satisfy the condition after their application. 

5.3.8 Preventing Condition Activation 

This problem is close to the problem of preventing side effects but considering 
conditions to be monitored instead of views. Given a transaction T, the problem 
of preventing condition activation is to find an additional set of insertions and/or 
deletions of base facts to be appended to T such that the resulting transaction T' 
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guarantees that no changes in the condition would occur as a consequence of the 
application of T\ In general, several resulting transactions may exist and the user 
should select one of them. 

5-4 Updates to an Inconsistent Database 

Sometimes it could be useful to allow for intermediate inconsistent database states, 
i.e. states where some integrity constraint is violated. This may happen, for instance, 
to reduce the number of times that integrity constraint enforcement is performed. 
In this case, three new problems related to update processing arise. 

5.4-1 Checking Consistency Restoration 

Given an inconsistent database state and a transaction that consists of a set of base 
fact updates, the problem of checking consistency restoration is to incrementally 
check whether these updates restore the database to a consistent state. 

Checking consistency restoration can be specified as performing deductive rea- 
soning on Sic, provided that Ic holds. In this case, deduced consequences on <5Ic are 
also either the identity substitution or no correct answer exists. If the identity sub- 
stitution is obtained, then the transaction induces a deletion of Ic and, therefore, 
restores the database to a consistent state. 

5-4-2 Repairing an Inconsistent Database 

Given an inconsistent database state, the problem of repairing an inconsistent 
database is to obtain a set of updates of base facts, i.e. a transaction, that re- 
store the database to a consistent state. In general, several solutions may exist and 
the database administrator should select one of them. 

The problem of repairing an inconsistent database can be specified as performing 
abductive reasoning on the event rules associated to <5Ic, provided that Ic holds. 
Given an EDB that violates some integrity constraint, abductive explanations for 
81c in -< EDB U IDB*, Ab y, with IDB = DR U IC, correspond to the possible 
transactions that would induce a deletion of Ic and that, therefore, would restore 
database consistency. 

5-4-3 Maintaining Database Inconsistency 

Given an inconsistent database state and a transaction T, the problem of main- 
taining database inconsistency is to obtain an additional set of base fact updates 
to be appended to the original transaction to guarantee that the resulting database 
state remains inconsistent. 

Maintaining database inconsistency can be specified as performing abductive 
reasoning on the goal <— T A — i5Ic, provided that Ic holds, with an abductive 
framework ^ EDB U IDB*, Ab with IDB = DR U IC. Although we do not 
see for the moment any practical application of this problem, it can be naturally 
classified and specified in the framework we propose in this paper. 
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5.5 Combining Different Problems 

In previous sections, we have assumed that deductive or abductive reasoning is 
performed on the event rules associated to a single derived event predicate. However, 
this framework can be easily extended to consider several derived events instead of 
only one. Deductive or abductive reasoning on a set of derived events is performed 
by considering the conjunction of all derived events in the set as the goal to be 
reasoned about. For instance a view update request consists, in general, of a set of 
insertions and/or deletions to be performed on derived predicates, e.g. u = tP(a) 
A iQ(b)A <5S(c) stands for the request of inserting P(a) and Q(b) and deleting 
S(c), being P, Q and S derived predicates. In this case, translations that satisfy u 
correspond to the abductive explanations for ;P(a) A iQ(b) A <5S(c) in -<! EDB U 
IDB*, Ab >-. 

Moreover, we would like to notice that deductive problems can be naturally 
combined. All of them share a common starting-point (a transaction that consists of 
a set of base fact updates) and aim at the same goal (to define the changes on derived 
predicates induced by this transaction). The same reasons allow the combination 
of abductive problems. Therefore, we can specify more complex database updating 
problems of deductive or of abductive by considering possible combinations of the 
problems specified in section |3J 

For instance, given a transaction T, a materialized view View, a condition to be 
monitored Cond and the integrity constraint predicate Ic, we could combine mate- 
rialized view maintenance, integrity constraints checking and condition monitoring 
by reasoning deductively on tView(x) A 5Cond(y) A -idc. Deduced consequences 
on tView(x) A <5Cond(x) A -itlc correspond to the values x and y that cause an 
insertion of View, satisfy the condition <5Cond as a consequence of the application 
of T, and such that T does not violate any integrity constraint. 

In a similar way, we could also combine view updating with integrity constraints 
maintenance by reasoning abductively on tView(a) A ->lIc. In this case, abductive 
explanations for iView(a)A->iIc correspond to the translations that satisfy both the 
insertion of View (a) and that do not violate any integrity constraint. 

Furthermore, we could also combine deductive and abductive problems. Note 
that the result of performing abductive reasoning is exactly the starting-point for 
performing deductive reasoning, that is, a transaction that consists of a set of 
base fact updates. Therefore, we could first deal with abductive problems and, 
immediately after, use the obtained result for dealing with the deductive ones. 

For instance, we could be interested on distinguishing between integrity con- 
straints to be maintained and integrity constraints to be checked, and on combin- 
ing view updating with the treatment of both kinds of constraints. In this case, we 
should first reason abductively on the view update request and the set of integrity 
constraints to be maintained and, later on, to consider the resulting transactions 
and reason deductively on the set of integrity constraints to be checked to reject 
those resulting transactions that violate some constraint in this set. 

Finally, we would also like to notice that in our approach for the specification 
of database updating problems does not change when considering other kinds of 
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updates like insertions or deletions of deductive rules. In this case, we should first 
determine the changes on the transition and event rules caused by the update and 
apply then our approach. 

6 Using Existing Procedures to Reason on the Event Rules 

Our framework to classify database schema validation and updating processing 
problems is based on the existence of a set of rules, like the event rules, that define 
the exact difference between consecutive database states. By performing deductive 
and abductive reasoning on these rules, we can deal with all these problems in a 
uniform way. Therefore, our framework does not rely on the concrete method we use 
to perform either deductive or abductive reasoning. However, candidate methods 
to be used must satisfy several conditions. 

Given a method able to perform deductive reasoning in a certain class of deduc- 
tive databases, it should satisfy two requirements to tackle the deductive problems 
described in the previous section: 

a) The class of deductive databases considered by the method must allow ex- 
pressing at least the goals required to define these problems. 

b) The method must obtain all correct answers that satisfy the request. 

Similarly, given a method able to perform abductive reasoning in a certain class 
of deductive databases, it should satisfy two requirements to tackle the abductive 
problems described in the previous section: 

a) The class of deductive databases considered by the method must allow ex- 
pressing at least the goals required to define these problems. 

b) For schema validation problems, if there exists some explanation for a given 
request the method obtains such explanation (but not necessarily several or 
even all of them). For updating problems, the method must be complete, i.e. 
it must obtain all possible explanations that satisfy the request. 

In this section we show that there exists already some procedures able to compute 
each different form of reasoning on the event rules and we illustrate them by means 
of some examples. We show, in this way, the applicability of our approach. We 
would like to mention, however, that our aim is not that of comparing existing 
procedures but just to show they are able to handle several problems. 

6.1 Using SLDNF to Reason Deductively on the Event Rules 

Standard SLDNF resolution is a possible way for reasoning deductively on the 
event rules. Given an augmented database A(D) = (EDB, IDB*), a transaction T 
and a derived event u, the deduced consequences on u due to T correspond to the 
successful SLDNF derivations of the goal <— u that result in a computed answer 9i 
when considering the input set EDB U IDB* U T. 

Nevertheless, other proof procedures could be used instead of SLDNF resolution 
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like, for instance, bottom-up computation of the event rules. To motivate our dis- 
cussion and without loss of generality, we will assume that SLDNF resolution is 
used to reason deductively on the event rules. The following example illustrates 
how to perform deductive reasoning on the event rules. 



Example 5 

Consider again Examplc[5]and assume a transaction T which consists of the deletion 
of the base fact Fail-ex ( John) , in our notation T={<5Fail-ex(John)}. The correspond- 
ing deductive framework is: 



EDBUIDB*: Sign(John) 

Fail-ex(John) 

Cont(x) <— Sign(x) A -Fail-ex (x) 
tCont(x) <— Sign(x) A ^<5Sign(x) A 5Fail-ex(x) 
tCont(x) <— tSign(x) A -Fail-ex(x) A -itFail-ex(x) 
tCont(x) <— tSign(x) A <5Fail-ex(x) 
JCont(x) <- <5Sign(x) A ^Fail-ex(x) 
5 Cont(x) <— Cont(x) A iFail-ex(x) 
T: <5Fail-ex(John) 



<— iCont(x) 


1 

<— Sign(x) a 8Sif 


;n(x) a 8Fail-ex(x) 


2 


x = John 


<— 8Sign(John) 


a 8Fail-ex(John) 


3 


8Fail-ex(John) € T 


<— - 1 SSign(John) 


4 


<— 5Sign(John) fails 


[ 


] 


x = John 



Fig. 1. Computing answers for <— tCont(x) 



The SLDNF refutation of Figure H shows that T={5Fail-ex(John)} induces the 
insertion of Cont(John), i.e. 9 ={x=John}. Note that the SLDNF tree rooted at <— 
iCont(x) succeeds with a computed answer x=John. That means that the deletion 
of Fail-ex(John) induces an insertion of Cont(John). Selecting other rules at step 
1 of this tree does not result on any other successful branch and, thus, no other 
insertion of Cont is induced due to T. 
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6.2 Using Abductive Procedures to Reason Abductively on the Event 

Rules 

We show now how the Events Method (Teniente and Olive 1995), Inoue and Sakama's 
method (Inoue and Sakama 1998, Inoue and Sakama 1999) and SLDNFA (Dencckcr 
and Schreye 1998) may be used to perform abductive reasoning on the event rules 
and, hence, to deal with schema validation and updating processing problems. Other 
existing procedures could have been used as well like, for instance, (Kakas and 
Mancarella 1990) which was the first attempt to use abduction in a database con- 
text. However, we have just considered some of the most recent proposals since they 
can be understood in some sense as an evolution of the initial ones. 

A detailed discussion on the specific features and limitations of other (abductive) 
methods to perform view updating and integrity maintenance can be found in 
(Mayol and Teniente 1999). 

6.2.1 The Events Method 

The Events Method (Teniente and Olive 1995) takes the event rules explicitly into 
account to obtain all possible minimal sets T, on the EDB that satisfy a given 
update request on the IDB. It extends the SLDNF proof procedure to obtain all 
possible transactions T, and it has been proved to be sound and complete for 
stratified databases (Teniente and Olive 1995). Soundness of the method guaran- 
tees that the obtained transactions satisfy the update request, while completeness 
ensures that it obtains all minimal transactions. 

In this method, an update request u is a conjunction of positive and negative 
events (base and derived). Positive events correspond to updates that must be 
effectively performed during the transition from the old state of the database to 
the new state, while negative events correspond to updates that may not happen 
during this transition. 

Let D be a deductive database, A(D) its augmented database, u an update request 
and Tj a set of base events. In the Events Method, Tj satisfies the request u if, using 
SLDNF resolution, the goal <— u succeeds from input set A(D) U Tj. Each set T, 
is obtained by having some failed SLDNF derivation of A(D) U <— u succeed. The 
possible ways in which a failed derivation may succeed correspond to the different 
sets Tj that satisfy the request. If no Tj is obtained, then it is not possible to satisfy 
the requested update by changing only the EDB. 

Although the event rules define the exact difference between consecutive database 
states, making a failed SLDNF derivation succeed does not always guarantee the 
generation of minimal solutions only. Therefore, the Events Method includes also a 
final step to discard obtained non-minimal solutions. We must note that the Events 
Method may not terminate in the presence of recursive rules because it may enter 
into an infinite loop. Moreover, as far as efficiency is concerned, it provides certain 
limitations on the treatment of rules with existential variables. 

Let u be an update request. In the Events Method, a transaction T satisfies u 
if there is a constructive derivation from (<— u 0) to ([ ] T C). The transaction 
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T contains the base event facts to be applied, while the condition set C contains 
base events (subgoals in the general case) that would invalidate the update request 
if applied. A constructive derivation is defined as follows (for convenience, let G/L 
stand for the goal obtained from a goal G by dropping a selected occurrence of 
literal L in G): 

Definition 6 

A constructive derivation from (Gi Ti Ci) to (G„ T„ C„) via a safe computation 
rule R (Lloyd 1987) is a sequence: 

(Gi Ti Ci), (G 2 T 2 C 2 ),. . . , (G„ T„ C„) 

such that for each i > 1, Gj has the form <— LiA. . .A Lfc, R(G,) = Lj and (Gj+i 
Tj + i Cj+i) is obtained according to one of the following rules: 

Al) If Lj is a positive literal and it is not a base event, then Gj+i= S, where S is 
the resolvent of some clause in A(D) with G, on the selected literal Lj, T i+ i = 
Ti and C J+ i= Q. 

A2) If Lj is a positive base event 'tP' (resp. '<5P'), there is a substitution a such that 
Pa does not hold (resp. Per holds) in the current database and there is a con- 
sistency derivation from (Cj T i U{L J cr} Q) to ({} T" C) then Gi + i=GiCr/Lj£r, 
T l+1 =T' and C i+ i= C. 

Note that if Q= or Lja G T 4 then G i+ i = G l a\L J a, T i+ i=T i U{L_ 7 -o-} 
andC i+ i= Ci. 

A3) If Lj is negative and there is a consistency derivation from ({<— ->Lj} Ti Ci) 
to ({} T' C), then G i+ i=Gi/L j; T i+1 =T' and C t+1 = C. 

Rule Al) is an SLDNF resolution step where A(D) acts as input set. In rule 
A2), the selected base event is included in the transaction set Ti to get a successful 
derivation for the current branch, provided that the event does not violate any of 
the conditions in Ci. In rule A3), we get the next goal if we can ensure consistency 
for the selected literal. 

Definition 7 

A consistency derivation from (Fi Ti Ci) to (F„ T„ C„) via a safe computation 
rule R is a sequence: 

(Fi Tx d), (F 2 T 2 C 2 ),..., (F„ T„ C„) 

such that for each i > 1, Fj has the form Hi U F\, where Hi =<— LiA. ..ALj and, 
for some j=l. . . k, (Fj + i T i+ i Cj+i) is obtained according to one of the following 
rules: 

Bl) If Lj is a positive literal and it is not a base event, thcnFi + i= S'UF'i, Ti + i = 
Ti and C,+i= Ci; where S' is the set of all resolvents of clauses in A(D) with 
Hi on the selected literal Lj and []^S\ Note that, if no input clause in A(D) 
can be unified with Lj, then S' = and F i+ i= F\. 

B2) If Lj is a positive base event, then Fj + i= S'UF'i, Tj + i= Ti and C,+i = 
CiU{Hi}; where S' is the set of all resolvents of clauses in Ti with Hi on 
the selected literal Lj and []^S'. If Lj is ground then Cj+i= Ci. 
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B3) If Lj is a negative literal, -ily is not a base event, k>l and there is a consis- 
tency derivation from ({<- -.Lj} T, C 4 ) to ({} T' C), then F i+1 = {Hi\L 3 -} 
U F'i, T i+ i= T andC i+ i= C. 

B4) If Lj is a negative base event, -Lj ^ Tj and k>l, then Fj_|_i= {Hi\Lj} U F'i, 
Tj + i= Tj and Cj.fi = C^. 

B5) If L-,- is negative, and there is a constructive derivation from ({<— ^Lj} Tj Cj) 
to ([] T' C), then F l+1 =F' l5 T i+1 =T' and C m = C. 

Rules Bl) and B2) are SLDNF resolution steps where A(D) or T act as input 
set, respectively. Rules B3) and B4) allow to continue with the current branch by 
ensuring that the selected literal Lj is consistent with respect to Tj and C,. In rule 
B5) the current branch is dropped if there exists a constructive derivation for the 
negation of the selected literal. 

Consistency derivations do not rely on the particular order in which selection 
rule R selects literals, since in general, all possible ways in which a conjunction 
<— Lj A. . . A Lj, can fail should be explored. Each one may lead to a different trans- 
action. As a result of this formulation, non-minimal solutions may be obtained. 
They are discarded by means of a simple procedure that rejects those that are a 
superset of the minimal ones. 

Example 6 

Consider again the same database as in Example0and assume now that the update 
request tCont(John) is requested. The corresponding abductive framework is: 

EDBUIDB*: Sign(John) 

Fail-ex(John) 

Cont(x) <— Sign(x) A -Fail-ex(x) 
tCont(x) ^Sign(x) A ^<5Sign(x) A <5Fail-ex(x) 
iCont(x) <— tSign(x) A -Fail-ex(x) A -iiFail-ex(x) 
iCont(x) <— tSign(x) A <5Fail-ex(x) 
<5Cont(x) <- <5Sign(x) A -. Fail-ex(x) 
<5Cont(x) <— Cont(x) A tFail-ex(x) 
Ab: { (.Sign, i5Sign, tFail-ex, <5Fail-ex } 

Figure [5] shows that the abductive interpretation of the event rules of Cont 
provided by the Events Method computes the abductive explanation T={<5Fail- 
ex(John)} for iCont(John). This is done by performing a constructive derivation 
rooted at <— iCont(John). Circled labels appearing at the left of the derivation are 
references to the rules of the Events Method we have just defined. 

The Events Method starts from the update request <— iCont(John) and uses 
SLDNF resolution pursuing the empty clause. Steps 1 and 2 are standard SLDNF 
resolution steps. At step 3, an abducible fact is selected. Then, it is included in the 
input set T and used as input clause if we want to get a successful derivation for 
<— iCont(John). 

Finally, at step 4, a negative base event literal is selected. Then, its corresponding 
subsidiary derivation must be considered, which is shown enclosed by the bold box. 
To ensure failure of this derivation it must be guaranteed that <5Sign(John) will 
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<— lCont(JohrQ 

© ' | 

Sign(John) a §Sign(John) a 8Fail-ex(John) 

(XT) 2 | Sign(John) e EDB 

<r- -< 8Sign(John) a 8Fail-ex(John) 
(A2) 3 | T= {8Fail-ex(John)} 

<— - 1 SSign(John) 
(A?) 4 J C = {<- SSign(John)} 

[] 

T = {SFail-ex(John)} 




Fig. 2. Constructive derivation for <— tCont(John) 



not be included into T later on during the derivation process. This is achieved 
by means of an auxiliary set C that contains conditions to be satisfied during the 
whole derivation process. These conditions correspond to some of the goals reached 
in subsidiary derivations, as shown at step 4.1 of Figure |21 where the condition 
<— <5Sign(John) is included in C. Hence, before adding a base event to T we must 
enforce that it does not falsify any of the conditions of C. 

Once the empty clause is reached in the primary derivation, the abductive proce- 
dure finishes and T gives the base events that, applied to the EDB, will satisfy the 
requested update. From this derivation we have that T={<5Fail-ex(John)}. Then, the 
request for inserting Cont(John) can be achieved by deleting the fact Fail-ex(John). 

Example 7 

Consider now the database of Example^] The abductive framework relevant to this 
example is: 

EDB U IDB*: Sign(John) 

Fail-ex(John) 
Some-cand <— Cand(x) 
Emp(x) <— Cand(x) A Cont(x) 
Cont(x) <— Sign(x) A ^Fail-ex(x) 
Ic2(x) 4— App(x) A -iHas-account(x) 
Ic4(x) 4- Cand(x) A ^App (x) 
Ic <- Ic2(x) 
Ic <- Ic4(x) 

tEmp(x) <— tCand(x) A iCont(x) 
tic <— dc2(x) 
tic <— dc4(x) 

tlc2(x) <— tApp(x) A -iHas-account(x) A -itHas- account (x) 
Jc4(x) <— tCand(x) A ^App(x) A ^tApp(x) 
Ab: { tCand, JCand, tCont, JCont, tSign, i5Sign, tFail-ex, 
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<— lEmp(Marv) a -ale 

(5) 'I 

<- iCand(Mary) a iCont(Mary) a -nlc 

2 | T= {lCand(Mary)} 
- iCont(Mary) a ~alc 

j T= {iCand(Mary), 
lCont(Mary)} 



© 



T= jlCand(Mary), iCont(Mary), 

lApp(Mary), iHas-account(Mary)} 



© 
© 




- iApp(x) a -^l-Ias-acconnl(x) a ^lHas-accounl(: 



C = {(- lApp(x) / 



ml(x) a -^iHas-account(x)} 



— iApp(x) a ^Has-accounl(x) a ^iHas-account(x) 
^B?) 4.5bl | iApp(Mmy) e T 

- ~\ las-acauinKMary) a ^iHas-accoimt(Mary) 

4.5b2 | Has-account(Mary) 
<- ""iHas-accQiinl(Marv) 
4.5b3 | 
fails 



© 



llc4 

4.2b | © 

iCandfx) a ~App(x) a -aApp('x) 

lCand(Mary) e T (^) 
C' = CU{+- iCandfx) a -^Appt(x) a - tApp(x)} 



4.3 b 



- ~App( Mary) a ^lApp(Mary) 
4.4b | <- App(Mary) fails 
<r- -'iApp(Marv) 

T= {iCand(Mary), 



4.5b 
fails 



iCont(Mary), 
lApp(Mary)} 



© 



Fig. 3. Constructive derivation for <— i Emp(Mary) A -> tic 



5Fail-ex tApp, <5App, tHas-account, JHas-account} 

Assume that we want to insert the derived fact Emp(Mary) without violating 
any integrity constraint. In this case, the abductive interpretation of tEmp(Mary) 
A-i/Ic defines the possible sets Tj, {tEmp(Mary)} C Tj, that do not induce ilc. This 
is shown in Figure 

As it happens in the Example HJ the Events Method starts from the update 
request *— tEmp(Mary) A -i&Ic and uses SLDNF resolution pursuing the empty 
clause. In this case, base event facts tCand(Mary) and tCont(Mary) are included in 
the translation set Tj during steps 2 and 3 of the primary constructive derivation. 
At step 4, the subsidiary consistency derivation (enclosed by the bold box) rooted 
at ilc must fail finitely to get the empty clause in the constructive derivation. Steps 
4.1a and 4.2a of this subsidiary derivation are SLDNF resolution steps. After this 
step, a failed goal is reached and it is included in the condition set C to guarantee 
that latter additions to T do not make it succeed. 

Steps 4.1b to 4.4b are SLDNF resolution steps, with the extension that the goal is 
included in C at step 4.3b. At step 4.5b, we have, in turn, a subsidiary constructive 
derivation (not shown in the previous figure) which is handled in the same way as 
the primary constructive one. This derivation causes the inclusion of tApp(Mary) 
into T. Moreover, it must be ensured that this inclusion does not violate any of 
the conditions in C. This is done by means of the subsidiary derivation rooted at 
^— iApp(x) A -iHas- account (x) A Has- account (x) which, in turn, requires the 
inclusion of tHas- account (Mary) into T (this is done in the constructive derivation 
associated to step 4.5b3, which is not shown in Figure El . 

Once the empty clause is reached, the abductive procedure finishes and T contains 
the base events that satisfy the requested update. From this derivation we have that 
Ti={tCand(Mary), tCont(Mary), tApp(Mary), iHas-account(Mary)}. This is the 
only solution that satisfies the requested update in this example. 
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6.2.2 Inoue and Sakama's Method 

In this proposal (Inoue and Sakama 1998, Inoue and Sakama 1999), an abductive 
logic program ALP is defined as a pair -< P, A >- where P is a normal logic program 
and A is a set of abducible atoms. Given an ALP, Inoue and Sakama define a set of 
production rules, its transaction program tP, that declarativcly specifies addition 
and deletion of abductive hypothesis. Abductive explanations are then computed 
by the fixpoint of the transaction program using a bottom-up model generation 
procedure. 

They consider two possible kinds of explanations: positive and negative. Given an 
ALP -< P, A >- and an observation G, a set of hypothesis E is a positive explanation 
for G if P U E |= G and P U E is consistent. Similarly, a set of hypothesis F is a 
negative explanation for G if P\F |= G and P\F is consistent. 

Moreover, they apply abduction also to "unexplain" an observation (look for 
antiexplanations). Given a normal logic program P and an observation G, a set of 
hypothesis E is a positive anti- explanation for G if P U E Y= G and E is consistent. 
Similarly, a set of hypothesis F is a negative anti- explanation for G if P\F ^ G and 
E is consistent. 

Their method has been shown sound and complete for covered acyclic normal 
logic programs. A normal logic program P is covered if, for every rule in P, all 
variables in the body appear in the head. In particular, this restriction does not 
allow having non-ground integrity constraints neither existential variables in the 
body of rules. 

There is a clear correspondance between looking for (negative) explanations that 
explain/uncxplain an observation and the kind of updates we can consider with 
the event rules. In particular, a positive explanation (anti-explanation) E is a set 
of event facts to be inserted (i.e. a set of base insertion events) while a negative 
explanation (anti-explanation) F is a set of event facts to be deleted (i.e. a set of 
base deletion events). Moreover, to explain an observation G that does not hold in 
the current database corresponds to consider the update request lG, to unexplain 
G (which holds in the current database) corresponds to consider the update request 
<5G. 

We may use Inoue and Sakama's method to reason abductively on the event 
rules. We have to: 

1. Consider the ALP -< P*, A >- where P* is the augmented database of P and 
A is the set of base event facts (both insertion and deletion). 

2. To include the following rules in the transaction program rP*: 

- For each base fact q that belongs to the EDB, we have to include the rule: 
in(tq) — > false. 

- For each base fact q that does not belong to the EDB, we have to include 
the rule: in(<5q) — > false 

These rules are needed to distinguish event predicates from database ones 
and to guarantee that an event can be successfully applied. 
Furthermore, since events (and events facts) are handled in this way, we also 
require to apply rule 3 of the definition of transaction program as defined in 
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page 346 of (Inoue and Sakama 1999) only to base facts, and not to apply it 
to events facts. This rule states that for any atom A that does not appear in 
the head of any rule in P we must introduce the production rule out(A) — > e 
and if A is not abducible we must introduce also in(A) — > false. 
3. To perform abductive reasoning on a derived event fact tp (resp. 6p), we have 
to explain tp (resp. 5p). On the other hand, to perform abductive reasoning 
on a negative derived event fact -iip (resp. ~<Sp), we have to unexplain -itp 
(resp. ~<Sp). 

As a result of applying Inoue and Sakama's method according to the previous 
transformations we obtain several explanations -< Ei,Fi y. For each such expla- 
nation -< Ei,Fi y, Ei corresponds to the abductive explanation that satisfies the 
request while Fi contains base events that may not belong to Ei. 

Note that the sets Fi play a similar role than the condition set in the events 
method. However, due to the restrictions imposed by Inoue and Sakama's method, 
each Fi contains only base event facts while the condition set contains more general 
goals. 

Example [3] [adapted from example 3.2 of (Inoue and Sakama 1999)] illustrates 
the use of Inoue and Sakama's method to perform abductive reasoning on the event 
rules. 

Example 8 

Let -< P, A y be an ALP where: 

P: P^PAnA 
Q <---C 
C «- 

A : A, C 

The relevant rules of P* are the following: 

P: iP <- lQ A -i A A -itA 

iQ «- 5C 

and the new abducibles atoms are SC, tA, iC, SA. 

Then, the subset of tP* obtained for the previous rules becomes: 
in(tP) -> in(tQ) A out(A) A out(tA) 
in(/.Q) -> in (SC) 

Now, to perform abductive reasoning on tP we have to compute the explanations 
for iP. Figure 01 shows the behaviour of Inoue and Sakama's method in this case. 
Note that, as a result, we have obtained the minimal explanations for tP: -<E, F^ 
= -<{in(<5C)}, {out(tA)}^. That means that to insert P we should delete C. 

^From the previous example, we can conclude that Inoue and Sakama's method 
is not only applicable to the update problems they mention in (Inoue and Sakama 
1998, Inoue and Sakama 1999), mainly view updating and satisfiability checking, 
but also to the rest of schema validation and update processing problems in covered 
acyclic databases. 

Moreover, by explicitly considering the event rules, this method is able to perform 
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Fig. 4. Computing explanations for *— tP 



more precise requests. It is not difficult to see that in (Inoue and Sakama 1999) an 
anti-explanation of P takes two different cases into account: whether P is false in the 
old state of the database and it is not inserted during the transition and whether 
P is deleted during the transition. By considering events about P we can be more 
specific since we can just look for anti-explanations of tP (which corresponds only 
to the second case). A similar claim can be made when looking for explanations. In 
fact, this distinction would allow them also to be able to define and handle dynamic 
integrity constraints. For instance, the dynamic constraint "it may not be inserted 
Joan as an employee and deleted the Sales department at the same time" may be 
specified as: <— tEmp(Joan) A (5Dept (Sales). 

Finally we must note that, in fact, Inoue and Sakama's method would not need to 
use the event rules to obtain the solutions of Example 03 However, we believe that 
the use of these rules could help this method to relax the restrictions it imposes 
on the programs it deals with. We will see in the next section other advantages 
provided by the event rules when more general conditions have to be taken into 
account. 



6.2.3 The SLDNFA Method 

Denecker and De Schreye propose SLDNFA (Denecker and Schreye 1998), an ex- 
tension of SLDNF resolution, to deal with abduction in abductive logic programs 
with negation. Given an abductive logic program and a query Q D to be explained, 
an SLDNFA computation can be understood as a process of deriving formulas of 
the form V (Q c <— "i"), where iff is obtained from the unsolved goals of the SLDNFA 
computation. 

In fact, SLDNFA distinguishes two kinds of abductive solutions. A ground abduc- 
tive solution for ^Q is a triple (£',A,#) with A a finite set of ground abducible 
atoms and 9 a substitution of the variables of Q c , both based on the alphabet E', 
such that P + A |= V (9 (Q G )). Similarly, an abductive solution for ^Q G wrt P A 
is an open formula \& containing only equality and abducible predicates such that 
P A \= V (Qc <— *) and 3( 1 3E f ) is satisfiable wrt P A . A ground abductive solution 
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can be considered as a special case of an abductivc solution since many ground 
abductive solutions can be drawn from 'J, in general. 

SLDNFA has been proved to be sound and complete for failure. Soundness ensures 
that the obtained solutions are correct since they entail the initial query and are 
consistent. Completeness for failure guarantees that if there exists a failed SLDNFA- 
tree for an initial query, then the query has no abductive solutions. However, this 
does not imply that SLDNFA generates all ground abductive solutions or all ground 
solutions satisfying some minimality criteria, as already pointed out by Denecker 
and De Schreye (Denecker and Schreye 1998), page 138. Two variants of SLDNFA, 
namely SLDNF° and SLDNFA + , are defined for which stronger completeness results 
are proved. 

SLDNFA can also be used to perform abductive reasoning on the event rules. 
To do it, we should first rewrite event and transition rules to guarantee that they 
explicitly state the event definition and, thus, that the events are correctly handled 
by SLDNFA. That is, for each event literal tQ(x) appearing in the body of an event 
or transition rule we should add the literal -iQ(x) to that rule, while for each event 
literal <5Q(x) we should add the literal Q(x). This rewriting is equivalent to the 
addition of new rules in Inoue and Sakama's method to guarantee that an event 
can be successfully applied. 

Then, we should take the Augmented Database (corresponding to the rewritten 
rules) as the abductive logic program P A where SLDNFA is applied and consider 
base event predicates as the only abducible predicates. 

Denecker and De Schreye already mention the applicability of SLDNFA (and 
its variants) to other problems and, in particular, to satisfiability checking. ^From 
the use of SLDNFA to perform abductive reasoning on the event rules, we can 
conclude that SLDNFA is also applicable to the rest of schema validation and 
update processing problems. Furthermore, dynamic integrity constraints can be 
easily specified by means of event and transition rules and, thus, they could also be 
handled by SLDNFA. 

Example|21[a simplified version of the example in p. 119 of (Denecker and Schreye 
1998)] illustrates the use of SLDNFA to perform abductive reasoning on the event 
rules. 

Example 9 

Consider the following deductive database: 
Q(a) 

P(x) «- R(x) A -Q(x) 
The abductive logic program P A corresponding to the previous database is: 

(7.1) tP(x) <-R(x) A -n<5R(x) A Q(x) A -.5Q(x) 

(1.2) tP(x) <- ~.R(x) A iR(x) A -.Q(x) A -ntQ(x) 

(1.3) «P(x) <- -.R(x) A iR(x) A Q(x) A 5Q(x) 
Abducibles: { iR, <5R, lQ, 5Q } 

An SLDNFA- refutation to find abductive solutions for tP(a) (which corresponds 
to the initial query <— tP(a)) is shown in Figure ElThe ground abductive answer 
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+ lP(a) 
+ = R(a), vR(a), Q(a), 5Q(a) 
+ iR(a), Q£a), 8Q(a) 
+ iR(a), 8Q(a) 

Fig. 5. SLDNFA-refutation for <- tP(a) 

generated by this refutation is (£,{tR(a), <5Q(a)},e). This answer states that the 
insertion of P(a) may be achieved by the insertion of R(a) and the deletion of Q(a). 

The use of the event rules provides also other contributions to SLDNFA. For 
instance, it allows SLDNFA to obtain solutions that would not be generated oth- 
erwise. For instance, SLDNFA (as defined in (Denecker and Schreye 1998)) would 
not obtain any solution to the request insert P(a) in Example The reason is 
that SLDNFA considers only positive explanations, but no negative explanations 
(according to the terminology of Inoue and Sakama (Inoue and Sakama 1999)). 
Therefore, it can not generate the deletion of Q(a) which is required to insert P(a). 
We have shown in Figure |3] that the use of the event rules allows SLDNFA to obtain 
such kind of solutions since abducing events corresponds always to the generation of 
positive explanations although an event may correspond to a deletion of a database 
atom. 

Another limitation that is overcome by the use of the event rules is that a direct 
application of SLDNFA to integrity constraint maintenance is not incremental. 
That is, it does not exploit the fact that the old database satisfies the integrity 
constraints, but rechecks blindly all of them (Denecker and Schreye 1998) (page 
158). Again, such situation can also be overcome if SLDNFA is used in conjunction 
with the event rules, as shown in Example 1101 

Example 10 

Consider the following deductive database: 

Q(b) R(b) Q(c) R(c) Q(d) R(d) 
Ic <— Q(x) A -.R(x) 
The abductive logic program corresponding to the previous database is: 
{1. 1) Jc <-Q(x) A -.<5Q(x) A R(x) A ->SR(x) 

(1.2) Jc «- -.Q(x) A iQ(x) A -.R(x) A ->tR(x) 

(1.3) Jc «- -.Q(x) A iQ(x) A R(x) A SR{x) 
Abducibles: { tQ, SQ, tR, <5R } 

An SLDNFA-refutation to find abductive solutions for tQ(a) that do not violate 
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+ lQ(a), ^ilc 




--Q(a),-R(a) != iR(al 
4 \|/ 
+ lR(a) 

Fig. 6. SLDNFA-refutation for <- iQ(a) A -.tic 

integrity constraints (which corresponds to the initial query <— iQ(a)A ^tlc) is 
shown in Figure EJ 

The ground abductive answer generated by this refutation is (£,{iQ(a), tR(a)},e). 
Note that, in this case, integrity constraint maintenance has taken into account that 
integrity constraints are satisfied before the update since it has only considered the 
events that could induce a violation of Ic (and not all database facts involved in 
the definition of Ic, as SLDNFA would do in the absence of the event rules). 

6.2.4 How many Methods do we really need to deal with Database Problems? 

In general, research related to database problems is still looking for methods able 
to deal only with specific problems. However, we have shown that all problems are 
either of abductive or deductive nature and, thus, they can be formulated in terms 
of just two forms of reasoning. Therefore, we may conclude from our results that 
at most two different procedures are enough to handle all of them. 

In fact, it could also be argued that just one single general procedure would be 
enough since it has been shown that either abduction as well as deduction can be 
realized in terms of the other. For instance, (Bry 1990, F.Bry, Eisinger, Schutz and 
Torge 1998) have proposed a procedure that allows to perform abductive reasoning 
by means of deduction, while (Denecker and Schreye 1998, Inoue and Sakama 1999) 
have shown that their abductive procedures can also be used for deduction. Clearly, 
this strengthens our claim that we do not need a different method to deal with each 
schema validation and update processing problem. 

The discussion about whether it would be better to have just one single method or 
two is far beyond the scope of this paper since it requires to be further investigated. 
From our intuition, we think that it will be difficult to define a single method which 
is as efficient to perform abductive reasoning as it is to perform deductive reasoning 
since, as we have shown in the paper, the nature of the corresponding problems is 
intrinsically abductive or deductive. In this sense, we believe that it is difficult to 
incorporate the optimizations required to efficiently deal with deductive problems 
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into a method based on abductive reasoning (and the other way around). However, 
this is still an open problem and it is a challenger research. 



7 Using the Event Rules to Perform General Abductive Reasoning 

We have shown how the event rules can be used to deal with several schema valida- 
tion and update processing problems and we have illustrated how several deductive 
and abductive procedures can be used to reason on them. In this section, we sketch 
how the event rules can be used also to solve general abductive problems in ad- 
dition to the database problems considered before. Obviously, we must take into 
account that whenever we use the event rules we obtain solutions that minimize 
the difference between the old and the new sates and that this is not necessarily a 
requirement that the abductive explanations must satisfy in general. 

We illustrate, by means of the following example, how could we use the event 
rules to deal with a typical abductive task like fault diagnosis and how the expected 
solutions to this problem can be abduced from these rules. 

Example 11 

The relevant part of the abductive framework of this example is the following: 

EDB U IDB*: Lamp(Ll) 

Battery(Cl,Bl) 

Faulty-lamp <— Lamp(x) A Broken(x) 
Backup(x) <— Battcry(x,y) A -iUnloaded(y) 
Faulty-lamp <— Power-failure(x) A ^Backup(x) 
Unloaded(x) <— Dry-cell(x) 
(Faulty-lamp <— Faulty-lamp" A -Faulty-lamp 
Faulty-lamp™ *— (Power- failure (x) A Backup(x) A (5Backup(x) 
Faulty-lamp™ *— (Power-failure (x) A ^Backup(x) A -i(Backup(x) 
Faulty-lamp™ *— Lamp(x) A -i<5Lamp(x) A (Broken(x) 
<5Backup(x) <— Battery (x,y) A (Unloaded(y) A Backup"(x) 
(Unloaded (x) <— (Dry-cell(x) 
Ab: { (.Broken, i5Broken, (Power-failure, (SPower-failure, (.Dry-cell, <5Dry-cell } 



Within this framework, we can use the event rules to detect that a faulty lamp 
problem is caused by a broken lamp or by a power failure of a circuit without 
backup, that is, a loaded battery. To do it, we have selected the Events Method 
among the three possible abductive procedures considered in Section lfi.21 

Figure0shows how, given the goal <— (Faulty-lamp and EDB U IDB*, the Events 
Method obtains the abductive solution T={(Power-failure(Cl), (Dry-cell(Bl) }, 
which is a possible solution for having a faulty lamp. 

The Events Method would also obtain the solution T={tBroken(Ll)} by consid- 
ering the rule Faulty-lamp™ (x) «— Lamp(x) A (5Lamp(x) A (Broken (x) at step 2 of 
Figure[3 and other possible solutions, like for instance T={tPower-failure(C2)}, by 
considering the rule Faulty-lamp™ (x) <— (Power- failure(x) A Backup(x) A-i(Backup(x) 
also at step 2. The resulting derivations are not shown in the tree above. 
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<— iFaulty-lamp 

1 | 

<— Faulty-lamp" a Faulty-lamp 

2 | 

<— iPower-failure(x) a Backup(x) a ^SBackup(x) a ^Faulty-lamp 

3 | 

<— iPower-failure(x) a Backup(x) a 8Backup(x) 

4 | 

<— iPower-failure(x) a Battery(x.y) a ^Unloaded(y) a 8Backup(x) 

5 | x=Cl,y=Bl 

<r- iPower-failure(Cl) a -^Unloaded(Bl) a SBackup(Cl) 

<— tPower-failure(Cl) a 8Backup(Cl) 

7 | T=flPower-failure(Cl)} 
<- SBackup(Cl) 

8 | 

<- BatteryfCl.y) a lUnloaded(y) a -Backup°(Cl) 

9 | y=Bl 

<- tUnloaded(Bl) a -Backup"(Cl) 

10 | 

<- tDry-cell(Bl) a -Backup n (C 1 ) 

11 | T= flPower-faiturefCl), iDry-cdl(Bl)j 

^ ^Backup-fCD 

12 | 

[] 

T=jlPower-failure(Cl), tf)ry-cell(Bl)} 



Fig. 7. Constructive derivation for <— iFaulty-lamp 

8 Conclusions and Further Work 

We have shown that database schema validation and update processing problems 
can be classified into problems of either deductive or abductive nature according 
to the reasoning paradigm that is more adequate to solve them. This has been 
done by making explicit the exact changes that occur in a transition between two 
consecutive states of the database by means of the event rules (Olive 1991) and by 
performing deductive and abductive reasoning on these rules. In this way we have 
distinguished between deductive problems, concerned with computing the changes 
on derived predicates induced by a transaction, and abductive problems, concerned 
with determining the possible transactions that satisfy a set of changes on derived 
predicates. We have also shown that deductive and abductive problems can be 
combined, thus defining more complex update problems. 

Thus, problems like materialized view maintenance, integrity constraint checking 
or condition monitoring are considered as naturally deductive, while problems like 
view updating, integrity constraint maintenance or enforcing condition activation 
as naturally abductive. 
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By taking only a unique set of rules and two forms of reasoning into account to 
specify and deal with all these problems, we have shown that it is possible to provide 
general methods able to uniformly deal with several database updating problems 
at the same time. This suggests that future research in this field should be aimed 
at providing general methods instead of proposing specific methods for solving a 
particular problem like has been traditionally done in the past. Moreover, all these 
problems could be uniformly integrated into a database update processing system. 

We have also shown how some existing general deductive and abductive proce- 
dures may be used to reason on the event rules. In this way, we have shown that 
these procedures can be used to deal with all database problems considered in this 
paper. This has been illustrated by means of examples and some additional bene- 
fits gained by these procedures when reasoning on the event rules have also been 
pointed out. Moreover, we have sketched how the event rules could be used to solve 
general abductive problems in addition to database schema validation and update 
processing problems. 

The results presented in this paper may be extended at least in three different 
directions. First, our framework could be generalized to databases that allow recur- 
sive rules. Second, to deepen in the study of the application of the event rules to 
current abductive procedures to provide an efficient implementation of abductive 
reasoning on the event rules. Third, the advantages and inconveniencies of using the 
event rules to perform general abductive reasoning should be further investigated. 
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